Open scripting opened 5 years ago
@stympy -- thanks for the suggestion.
My first question is this -- are there any services that offer hosting of dokku?
And of course there is a howto for Digital Ocean which I will read. ;-)
https://auth0.com/blog/hosting-applications-using-digitalocean-and-dokku/
Dave
Interesting timing. Digital Ocean introduced a new Kubernetes service yesterday.
https://blog.digitalocean.com/digitalocean-releases-k8s-as-a-service/
Dave
Heroku/Dokku is fine for one-off apps. But If you have a stack that includes many applications or an application composed of many services, then Kubernetes is probably a good idea. If you already pay for large infrastructure resources, Kubernetes can be used to get better utilization of those resources.
Pretty much everything I have is "one-off" apps if I understand correctly.
What would be an example of an app that needs Kubernetes?
GitHub probably, right?
Twitter...
Anything with millions of users?
I see Kubernetes (k8s) as standardizing the technology and practices (12 Factor apps, DevOps, etc) that a Heroku would use to build and operate a platform-as-a-service. But not just for types of applications specifically supported by Heroku, but for anything that can run in containers.
You have enough individual apps, that you could either run them in separate servers(virtual or physical) or in separate Heroku projects; or you could run them all in the same cluster. K8s enables one to specify a virtual cluster that can be provisioned onto any collection of infrastructure that implements the k8s APIs (ranging from a laptop to a cluster with 1+ bare metal or virtualized servers).
A single app consisting of 3 or more interacting services would need something like k8s, especially if you wanted flexible scaling, self-healing or needed fine grained control of how components were deployed. So yeah, an app that needs to scale to support millions of users would be an example.
A stack with multiple individual apps where you wanted unified interfaces for monitoring and administration of each workload could use Kubernetes. In order words, you want to manage your apps, not the servers they run on.
Another app that needs Kubernetes would be a service that needs to scale up from zero based some event like a customer request or API call. (e.g. AWS Lambda or Google Cloud Functions or code sandbox apps like repl.it or Glitch).
@corntoole -- thanks for the explanation!
What does "cluster" mean in this context?
I'm currently working on an application deployed on a Kubernetes cluster.
To me Kubernetes solves a different problem than Heroku. Where they both are about application hosting, herok seems focused on speed and ease of deployment for a developer. What we call a "Platform as a Service". They provide a databases and a runtime, you give them source code and configuration, and you're off to the races.
Kubernetes is technology lower in the stack. The problem it is focused on is: how do I manage multiple applications running on multiple machines? let's say, for example, I have three servers. To serve my application, I have a MySQL database and an API server. I get a lot of traffic, so maybe I want to run multiple copies of the API server. Which machine do I run what on? What do I do if I need to add a third instance of the API server?
Kubernetes says, "Let me handle that" You put Kubernetes in charge of all your servers, and it gives you a "cluster". Think of it as a super-server. (Maybe it's 3 machines, maybe it's 5, it doesn't matter).
Then you tell kubernetes about your applications: "I need two copies of API server that each need 1 CPU and 256Mb RAM" and 1 copy of MySQL that needs 0.5 CPU and 256Mb RAM. It decided how to spread the work across the servers.
You can add and remove servers to and from the "cluster" as you need, but you don't need to think about what runs where.
There are more sophisticated things you can do with it as well, but this is the basic gist.
I have found hosted kubernetes quite easy to use for simple combinations of apps. Running it yourself is where a lot of the "complicated" talk comes from, as you are generally setting up a datacentre with cpu, storage, ....
The config is yaml based, so I wouldn't suggest it to non-tech family yet.
If you have a one-piece app (stateless, or state in hosted service such as s3) then package it into a container. Your favourite cloud probably offers a simple interface for running it, keeping it up, and even autoscaling. No need to complicate things with kubernetes.
:+1: to what @corntoole and @tedchoward said.
TL;dr: If Heroku works fine, don't worry about Kubernetes at all. People are excited about Kubernetes because it fills in a gap in between Heroku and AWS, because it helps minimize AWS lock-in, and because it isn't completely terrible. If you do try Kubernetes, plan on reading an introductory book first. Don't install or manage Kubernetes yourself.
Heroku vs. a private server vs. Kubernetes
Dockerfile
With a Dockerfile
, you can run your program locally on your computer, on Heroku, or using Kubernetes. It's basically a universal "cargo container" for server software; all the vendors can run it.
You only want a Dockerfile
when a package.json
isn't enough to get your app running.
A Dockerfile
is basically like a package.json
file, except you get to customize the virtual machine. Pick a distro! Install some packages! Run npm package install
.
Before using Kubernetes, you need to learn how to make a Dockerfile
for a Node app, and how to run it on your computer using docker run
. Here's an example, adapted from this tutorial:
# Specify what version of Node to use.
FROM node:8
# Create app directory.
WORKDIR /usr/src/app
# Install app dependencies. (We do this first so we can cache it and not
# need to re-run `npm install` unless we change the package files.)
COPY package*.json ./
RUN npm install
# Bundle the rest of the app source.
COPY . .
EXPOSE 8080
CMD [ "npm", "start" ]
The whole tutorial is good, and it will show you how to build and run your app using the above Dockerfile
.
What Kubernetes is like on a day-to-day basis
Basically, you write some YAML files describing all the things you want Kubernetes to create (applications, databases, disks, load balancers, etc.). Here are some examples for an RSS reader. Then you run:
kubectl apply -f my_big_app.yml
...and Kubernetes creates everything, making sure you have enough servers, creating any virtual disks you need, etc. If you get something wrong, or want to scale up, just edit the YAML file and re-run kubectl apply
.
Basically, you spend all your time Googling for sample YAML templates, tweaking them, and apply
ing them. It's not too bad.
You can even install support for new kinds of "resources". For example, gitkube basically turns your Kubernetes into something more like Heroku, complete with git push
.
You can also find YAML templates that say, "Run one copy of the monitoring program described by this Dockerfile
on each of my physical servers, automatically."
It mostly does what it promises. There are still some sketchy bugs (I spent 2 hours yesterday working around flaky Kubernetes 1.10 DNS, before giving up and hitting Google's "Updgrade my cluster to 1.11" button).
Kubernetes survival guide
So let's say you've decided that Heroku and package.json
just aren't enough, and—for some reason—you don't just want to throw it all on a VM. Here are two key steps that will prevent a lot of suffering:
What's really going on here
AWS is great! But it locks you into Amazon. Of course, Google, Microsoft, Digital Ocean, etc., all see that this is a problem. So do a lot of Amazon customers. And they all realize that we can't do everything on Heroku.
So Kubernetes is basically there to paper over 80% of the differences between the different cloud setups. It acts an interface to AWS, or Google Cloud, or to Digital Ocean. It abstracts away servers like Heroku does. It runs Docker containers. It can manage disks, hook up load balancers, manage rolling deploys, all that stuff.
But if your app runs fine on Heroku, run your app on Heroku.
very useful commentary - thanks!
I keep reading about Kubernetes and how it's taking over the world, but every piece also says it's very complicated. Why?
Heroku set the initial prior art in this area. It's easy to get started with. Here we are many years later, it seems we are going the wrong way. Or am I missing the point.
Isn't Kubernetes trying to solve the same problem as Heroku? In any case an open source user-deployable Heroku that was easy would be very welcome.