Swarm is such a pleasant and easy alternative that comes out of the box with Docker, does 90% of what Kubernetes does, and does 100% of what anyone with less than 50 servers needs. The learning curve is also an order of magnitude easier.
https://forums.docker.com/t/is-there-a-built-in-kubernetes-i...
https://blog.docker.com/2018/07/kubernetes-is-now-available-...
I just installed Docker via package manager so I guess I never really learned about the organization's offerings in total and didn't know which product I had (CE for Linux). Is there a more up-to-date/better practice for using Docker CE with k8s than this guide dated March[0] using Minikube[1]?
[0]: https://blog.sourcerer.io/a-kubernetes-quick-start-for-peopl... [1]: https://github.com/kubernetes/minikube
As for an app deployment tool I've had good success with Helm. It allows you to define all the services, app, variables, etc. that your app needs. Though the templates do seem to be a bit convoluted and hard to read at times if you aren't careful.
What I want is a Maven for Kubernetes. With transitive dependencies, strong conventions, injection of parameters etc.
The templating stuff feels very...unstructured to me. Every Chart is slightly different.
2. Haven't tried this, but I'm aware of it - does this address your point here ? https://www.telepresence.io/
3. Something like this? https://github.com/rycus86/docker-pycharm I agree that this could be very cool if further developed.
I agree that we'll start to see deeper integration across the development environment though, as more dev-hours are spent on building up the toolchain.
# Local development / testing
I use "minikube" for developing and testing each service locally. I use a micro service architecture in which each service can be tested in isolation. If all tests pass, I create a Helm Chart with a new version for the service and push it to a private Helm Repo. This allows for fast dev/test cycles.
These are the tasks that I run from a "build" script:
* install: Install the service in your minikube cluster
* delete: Delete the service from your minikube cluster
* build: Build all artifacts, docker images, helm charts, etc.
* test: Restart pods in minikube cluster and run tests.
* deploy: Push Helm Chart / Docker images to private registry.
This fits in a 200 LOC Python script. The script relies on a library though, which contains most of the code that does the heavy lifting. I use that lib for for all micro-services which I deploy to k8s.
# Testing in a dev cluster
If local testing succeeds, I proceed testing the service in a dev cluster. The dev cluster is a (temporary) clone of the production cluster, running services with a domain-prefix (e.g. dev123.foo.com, dev-peter.foo.com). You can clone data from the production cluster via volume snapshots if you need. If you have multiple people in your org, each person could spawn their own dev clusters e.g. dev-peter.foo.com, dev-sarah.foo.com.
I install the new version of the micro-service in the dev-cluster via `helm install` and start testing.
These are the steps that need automation for cloning the prod cluster:
* Register nodes and spawn clean k8s cluster.
* Create prefixed subdomains and link them to the k8s master.
* Create new storage volumes or clone those from the production cluster or somewhere else.
* Update the domains and the volume IDs and run all cluster configs.
I haven't automated all of these steps, since I don't need to spawn new dev clusters too often. It takes about 20 minutes to clone an entire cluster, including 10 minutes of waiting for the nodes to come up. I'm going to automate most of this soon.
# Deploy in prod cluster
If the above tests pass I run `helm upgrade` for the service in the production cluster.
This works really well.
No worries :) I use digitalocean for the nodes, storage volumes, etc. and namecheap to register the domains.
At namecheap I simply use the "Custom DNS" option for each domain to apply the digitalocean nameservers. I only have to do this once for every domain.
After that is done, I can use the digitalocean API, the "doctl" tool or the web-interface to handle domain records, subdomains, etc.
In order to connect a domain/subdomain to a k8s cluster, I point the domain/subdomain to the master node of a cluster. In each k8s cluster I use an "ingress" (nginx) [0] to handle the incoming traffic (directing each request to the right service/pod. You can think of it as a loadbalancer that runs within your cluster).
This strategy would work on other cloud providers (Azure, gcloud, etc) as well, I guess.
I was really hyped about Azure Dev Spaces (https://docs.microsoft.com/en-us/azure/dev-spaces/), but it's Azure only, even though it sounds like something that should work on any k8 cluster..
One vagrant VM allows you to make assumptions about what software is installed on a dev desktop which is especially useful if you're writing documentation. Getting into the Vagrant VM from various OSes is the main problem but once you're in... Then you can install container software and teach others how to work in docker given one assumed OS.
Since Vagrant and containers encourage some form of infrastructure/documentation as code, then more experienced developers can read through what goes into the Vagrant set up and replicate on their native OS if they prefer. As someone writing documentation, I can forget about those more experienced devs and just write to one OS.
Once you have documentation that you can guarantee works when using container software, much of the headache can be swept under the rug for more junior engineers which I think is the krux of the issue for others when using k8.
I'd very much like a Ruby/Python/Rust of cloud infrastructure to come along and clean up this mess.
Might be something like what you're after.
Docker swarm could be the step after dokku for when you'd ever need scaling and the like rather than just a bigger VPS for when the first one starts to feel small.
(I work for GCP)
1. Something that makes it easy to run the application(s) you're working on locally... 2. ...but have it interact with services in a local kubernetes cluster easily. 3. Something that makes your entire development environment effectively immutable, read-from-files the same way as the immutable infrastructure we're talking so much about. 4. Something that gives you a good start to running in production, so the first day of bringing your service up isn't a mess of trying to find/remember what environment variables/config options to set. 5. Something that's one tool, instead of a mixture of `minikube`, `kubectl`, `docker`, `draft`, and `telepresence`. 6. Something that's opinionated, and follows "convention over configuration", with conventions that make for the best future designs.
Basically, we need something with a Rails-like impact but in the Kubernetes ecosystem.