feat(ops): Kuberenetes

[zacanger]

Closes #116
Depends on #220

Open to PRs/patches! I'm still very new to Kubernetes, so please shout at me if you see any issues.

This is tested with microk8s. If anyone would be interested in testing on more production-like infrastructure I'd definitely welcome that. Otherwise, it should be ready to merge.

As mentioned in the comments, it would be neat to have a Helm chart, but with the Helm 2 to Helm 3 churn right now, I think that's something for the future.

[krainboltgreene]

FWIW: https://twitter.com/kelseyhightower/status/963413508300812295?lang=en

[zacanger]

Oh yeah, I definitely know. I think running postgres, redis, etc. in kubernetes should be an option here, but we should also allow it to work with externally hosted services (like RDS).

[krainboltgreene]

One solution I've come up with for projects is to instead provide a pgbouncer+pgpool interface. The application treats it like pg,so users don't care, then they just have to hook up a postgres instance. It still doesn't "scale" like kube expects to scale, but at least it doesn't delete data when you scale 0.

…

On Fri, Jun 7, 2019, 1:03 PM Zac Anger ***@***.***> wrote: Oh yeah, I definitely know. I think running postgres, redis, etc. in kubernetes should be an option here, but we should also allow it to work with externally hosted services (like RDS). — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#204?email_source=notifications&email_token=AACRXWOFW2XRXZLETKZUFMTPZK5JTA5CNFSM4HVZIQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXG3KHI#issuecomment-500020509>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRXWIBLNASI64QD67NNFDPZK5JTANCNFSM4HVZIQCA> .

[zacanger]

I'll be honest, I'm a total postgres noob, but I'll take your word for it. Is that something we should consider adding?

[krainboltgreene]

You want pgbouncer if you expect a lot of connections. You want pgpool if you have a LOT more reads than writes.

…

On Fri, Jun 7, 2019, 6:01 PM Zac Anger ***@***.***> wrote: I'll be honest, I'm a total postgres noob, but I'll take your word for it. Is that something we should consider adding? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#204?email_source=notifications&email_token=AACRXWOHPGC4UGNSYPE2HYLPZMAFRA5CNFSM4HVZIQCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXHJZ3A#issuecomment-500079852>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACRXWIT5FDIN45BMGXAQ6DPZMAFRANCNFSM4HVZIQCA> .

[zacanger]

@krainboltgreene I ended up removing Postgres from this entirely, since that seems like a decision admins should make (I know I'll end up just using RDS).

[ceejbot]

I can look at this, but I'm pretty sure I don't know enough to give it a meaningful review.

ETA: I generally don't want stateful things handled by k8s, as Kelsey Hightower's thread suggests. I see many potential users as wanting to hook up with RDS or some other hosted postgres service just to avoid having to do backups, upgrades, and other maintenance themselves. Same with redis, though there's no long-lived state in it in this design, and redis is operationally a lot nicer than postgres.

[zacanger]

That's pretty much how I feel about it. I am not a DBA and don't want to be one, and (maybe I'll end up being wrong about this, but) I don't think the target admin type user here is a DBA, or even an ops person. It's probably someone who cares about Node a lot, and may or may not have any database or operations experience.

Edit: I'm going to ask a coworker for a once-over tomorrow, since we have some extremely knowledgeable folks leading the move to k8s at $day_job.

[krainboltgreene]

I know quite a bit about this surface of application development and I would love to do a pair review to transfer the knowledge.

[krainboltgreene]

If I understand the misc/k8s directly I believe the current ecosystem leans towards using helm to do this job. Many many people will expect to be able to helm install entropic.

[zacanger]

I thought about using Helm, but with Helm 3 coming soon I didn't know if it would be worth doing things twice. Once Entropic is more stable I think it would make sense to try to get charts into the official helm/charts repo, though.

[krainboltgreene]

Agreed, and not having helm shouldn't stop this PR.

[Julusian]

Why are you converting to yaml here? The Kubernetes api accepts json too, but does recommend yaml. As this project is really against yaml, why not just keep it as json?

https://kubernetes.io/docs/concepts/configuration/overview/

Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly.

[zacanger]

Good point. I was converting them to YAML because that's much more common in the ops world, but it shouldn't really matter since it's already uncommon to write them in JS. I think I'll change that.

[chrisdickinson]

Thank you for this! It LGTM, as far as I can tell – I'm in the same boat as @ceejbot!

I'm going to add this to the merge queue & test it locally when merging. 💚

[1stvamp]

This is a great solution, and works well on microk8s and GKE.

There are a few rakes such as if you want to use your own psql deploy, and the usual issues of deciding which NodePorts you need exposed.

👍 to merging this now, and expanding on the doc as part of another PR with more steps to bring up a basic env - this would also make a good blog post.

[chrisdickinson]

Thanks for reviewing, @1stvamp! I've merged this in 6373162.

[zacanger]

Thanks @1stvamp and @chrisdickinson!