tl;dr - I switched from ployst/docker-letsencrypt which I considered less complicated than jetstack/kube-lego initially. Turns out jetstack/kube-lego is pretty simple and just works which is amazing, props to the team over at jetstack and as always the kubernetes team, for making this more intelligent automation possible. You could honestly just read the jetstack/kube-lego guide, it’s real good. If you wanna see my path through it, keep reading. Up until now I’ve been using ployst/docker-letsencrypt, and it’s been working fine, however I’ve longed for a solution that didn’t require me to manually kubectl exec scripts, and kube-lego is that tool.
tl;dr - Setting up piwik is pretty straight forward, since I’ve gone through the trouble of setting up a database before, and piwik’s web based setup is pretty convenient. This post is the last in the pipeline that’s related to Kubernetes for a bit. One of the most useful tools I’ve ever come across is Piwik – it’s an excellent self-hostable tool for doing web analytics like tracking visits to your website (this very site uses it as well).
tl;dr - Setting up Mailu on Kubernetes was pretty simple, once TLS and Ingress are all set up. It’s just a matter of configuring the ingress controller, adding the right ingress resources, and making the right resource configuration for Mailu. I encounter some (mostly self-inflicted) issues along the way, but you can find the resource config that worked for me at the end. Up until now on every VPS that I’ve purchased/used, I’ve manually set up Postfix and Dovecot and all the related services on the machine, navigating documentation, setting up additional users, adding virutal mailboxes, etc.
tl;dr - Rancher 2.0 is out, Check out the demo video, it’s pretty slick. I start to set up Rancher, mess up, do some debugging, and eventually get it working with a bit of a hack. Skip to the end section (named “The whole process, abdridged”) before wrap up to see the full list of steps I took for getting Rancher running on my own local single node Kubernetes cluster.
tl;dr - It’s pretty easy if you have let’s encrypt certificates set up, and Kubernetes Ingress/DNS working properly (I’ve covered how I set these up in previous posts so check them out for reference). Skim through to see the final Kubernetes resource configuration that I use in production for Passcue.me So far we’ve gone through a lot of Kubernetes related posts, from setting up Kubernetes manually on a single machine, to getting regular non-authenticated HTTP apps running on Kubernetes, to setting up a database on kubernetes and setting up letsencrypt-powered TLS certificates.
tl;dr - letsencrypt is awesome, ployst/docker-letsencrypt makes it easy to use with Kubernetes (feel free to check out the blog post that describes it). There are even easier ways to do it these days that I haven’t tried: kube-lego which looks pretty amazing. After going through figuring out how to run HTTP applications on Kubernetes, as well as how to run databases on Kubernetes, the next natural step is to figure out how to gear up to running HTTPS applications on Kubernetes.
tl;dr - I thought I needed PersistentVolumes but I don’t (I do go through how to use/activate them though), they solve a different problem. All I needed was the combination of a Volume + StatefulSet + Node Affinity + Service in order to get my database running on a single node consistently, and accessible through DNS. I also go through setting up High Availability (HA)/clustered RethinkDB but it’s probably wrong/not axiomatic Kubernetes so check out the section on why I think it’s wrong.
UPDATE This configuration previously contained LoadBalancer as the spec.type but it turns out that actually I don’t need to set it to LoadBalancer. Basically, LoadBalancers are for use in cloud provider environments, and create their own ingresses according to the documentation. This was pointed out to me by Thomas Barton who came across this post on HackerNews and I wanted to of course pass the information on. Check out the section with the configuration for the changes and a small explanation.
This is the third in a series of blog posts centered around my explorations and experiments with using Kubernetes and CoreOS to power my own small slice of infrastructure. Check out the previous posts: Part 1 (Setting up the server with CoreOS) Part 2 (Getting Kubernetes running) Part 3 (Setting up essential Kubernetes addons) (this post) tl;dr - Kubernetes has some pretty important addons like DNS and Dashboard, here I go through deploying them, and my thought process as I debugged issues.
This is the seccond in a series of blog posts centered around my explorations and experiments with using Kubernetes and CoreOS to power my own small slice of infrastructure. Check out the previous post: Part 1 (Setting up the server with CoreOS) Part 2 (Getting Kubernetes running) (this post) Part 3 (Setting up essential Kubernetes extras) tl;dr - Read the step-by-step guide on the CoreOS site for setting up Kubernetes, it’s excellent.