Overengineering the Deployment of Static HTML with CI/CD Docker and Kubernetes | Hacker News Reader

Overengineering the Deployment of Static HTML with CI/CD Docker and Kubernetes

medium.com

52 pointsmswehli17 comments

"Even my fiancée was impressed after I spent an hour over the phone explaining to her what I did exactly and a brief background on CI/CD, DevOps, Jenkins, Agile, Lean Start-ups, and some other high level concepts. She assured me she listened to everything I said and was very impressed, she only left the phone on speaker so that she could better take in everything I was saying."

Thanks for the write-up! I think building projects like this also cements the concepts in preparation for more complicated CI/CD systems.

One small correction: In the sentence "When copying over the config file, make sure to remove all breakpoints from the certificates. Otherwise this will cause a base64 decoding error in the build." I think you meant line breaks instead of breakpoints.

Thanks, glad you enjoyed it :) agree it serves as a great prep for doing more complicated things with it. Ahh, yes i did. thanks for letting me know about that!:)

Any reason you went with a DigitalOcean LB as opposed to using the DO DNS service pointing at Rancher's internal LB's?

I'm actually using azure, but basically I didn't want to dedicate a port on the cluster to the website, nor did i want to use any of the existing external networking infrasture/services for the website so it limits anyones ability to try to connect to my cluster directly. Also loadbalanced services on kubernetes are really quick to set up and azure sets up the loadbalancer automtically. If i were to add a second website to host on the cluster, i would probably do it through the nginx ingress controller though, and do host based routing to the correct service. That way i'd only need 1 lb and ip for all my services and deployments.

Why not S3 and Cloudfront or equivalent?

I used kubernetes because i already have a cluster running that i use for development. Instead of spinning out and paying for a new vm or app service to host it on (which cost the same basically), i found it makes more sense to create it as a docker image and launch it as a kubernetes deployment. Since we develop everything ourselves and don't have any features where users can upload anything, it works out to still be secure.

> Instead of spinning out and paying for a new vm or app service to host it on (which cost the same basically)

S3 / Cloudfront is (apologies for the buzzword) serverless and incredibly cheap. It's public-facing only though.

Oh sorry i actually confused S3 for aws ec2 for some reason >_< Didnt really think about it to be honest, but will give it a look. Long as it can be connected to my pipeline!

If you want to stick with Azure, blob storage (+CDN if you want both HTTPS and a custom domain) works pretty well and is dirt cheap.

Thanks i'll have a look. Though i feel like i might miss my loadbalancer :) kind of attached to it now. But cheap sounds great!

you won't need a load balancer... it will just serve infinite scale (effectively) as they take care of that automatically.

not resume generating enough

S3 and cloudfront isn't perfect. If you've got a lot of redirects the S3 config is a pain.

Getting the ACM certs is the big bonus though.

ive done that,but I used gitlab

Oh yeah, i mainly use visual studio online because i use .net a lot. Bet it makes website development so much easier now huh? bug fixes can basically be instant! :)

speaking of bug fixes, might check the spelling of your "The Service" button. ;)

Reply on news.ycombinator.com