Is there some standard "here are existing 10 services and in this guide we'll go through deploying them, securing them, installing service mesh, provisioning database..." kind of thing?
1. Containerisation - can you build a hello world web app in any language then Dockerise it.
2. Now break it into two containers - one is the original hello world but now it calls an API on a 2nd container that responds with hello world in one of 10 different languages. Just hard code this the point is that it’s now 2 containers for your “app”.
3. Create a Docker repository in GCP’s Artefact Registry and upload your images. Now remove them from your local Docker registry and run them again but this time pulling them from your registry on GCP.
3. Use Cloudbuild to build them.
4. Spin up a local Kubernetes cluster such as Minikube.
5. Read docos about K8s deployments and service types. Special attention to ClusterService, NodePort, LoadBalancer.
6. Deploy the first version of your hello world. Maybe try to point your YAML to the local registry then the one on GCP you created.
7. Create a service to access your app.
8. Figure out how to turn in and access (via proxy) the kubernetes dashboard.
9. Now deploy the 2nd version of your app. Learn a bit more about K8s networking, pod horizontal scaling, pod resource claims, kill some pods, etc.
10. Learn Skaffold.
11. Create GKE cluster.
12. Deploy same app.
13. Learn about K8s Ingress.
14. Get familiar with GKEs console.
15. Use knowledge of Skaffold to understand and use the brand new Google Cloud Deploy.
Edit: autocorrect “fixed” several things
If you know all of the points I listed before, have a look at GKE benefits like horizontal and vertical pod autoscaling, cluster autoscaling, istio, config connector, anthos
With regards to "understanding it," I mean knowing what it's doing under the hood. It's all well and good to know that you can install something by doing "helm install," but you should really know what helm install actually does.
With regards to "when it's useful," I mean when you have a very complex system that needs a high level of abstraction to make manageable.
With regards to "when it's not [useful]," I mean various scenarios. For example, when you really only need a single pod running with no configuration and no ingress, Helm is not only overkill, but also a negative, as it abstracts without adding any value.
The fact you add complex logic in the chart makes deployment logic problematic when debugging complex workflows because team1 instilled all the logic in the CI while team2 in the helm chart(!) and team3 50-50.
I prefer using bash + gnu utils (envsubst & see) and kustomize than playing around with a template language running on top of another … the funny part was that we run all this thing via Jenkins & bash. I recall having to use an inordinate number of escapes in some cases… anyway.
> when it's not: 100% of the time.
I see a lot of things that has to be solved on your own even when using Helm. I find their templates repulsive. But "avoid helm" is not an advise, really. How do you suggest to structure, version, deploy, encapsulate with important metadata your deployment descriptions? How do you package it? Is there anything else that integrate with larger tools like Rancher so well?
- Do the container 101 hands-on workshop (bottom of the page)
- Do the Kubernetes 101 hands-on workshop
- ???
- Profit! build and deploy applications on ANY kubernetes (not just GCP)
And then look into the GCP specifics for k8s (GKE), networking, DNS, load balancing, storage, monitoring, etc...
[1]: https://www.manning.com/books/kubernetes-in-action-second-ed...
Sure, you can get something basic running very quickly but if you are talking about production systems, "ramp up"? then there are many things to learn, understand and avoid and this takes an amount of time.
For an example, as a very experienced Dev and Ops person, after 18 months of Kubernetes, I am still learning things that I should have ideally done from day 1 and probably only avoided problems because I am not using it with very high traffic.
You can read lists and follow tutorials but engineering is trade-offs and even in the world of nice tooling, there are still many decisions to make and don't end up in a position where, for example, you cannot upgrade an ingress without the system becoming unavailable because you didn't consider this early on.
Don't get me wrong, it is worth learning but it is not fast.
* Working out/testing how upgrades can be made to ingresses without downtime
* Designing and testing SSL cert rotation
* Having a strategy for image version updates (e.g. not using "latest" but how to decide when an upgrade to a newer image is or isn't acceptable)
* How to super-optimise layering or image builds including ADD vs COPY, realising that copying everything at once usually breaks this, working out where/how to perform things like OS updates
* How to correctly inject build versions from CI into the docker executable
* How to use databases inside containers with e.g. schema and data updates
* The various kubernetes network options
* How DNS works in kubernetes (and when it doesn't)
* Debugging containers that fail to start or run
* Using probes correctly and understanding ready vs liveness vs startup
* How to check for node health dynamically to control external load balancers
* Using pod anti-affinity to balance pods across all nodes
* Understanding how to lof effectively from the container
Those are a few I can think of off the top of my head.
You don’t have to do all of it, just enough to feel comfortable with the problem space that containers in part are trying to solve for. In doing so you will learn about the fundamentals of the stacks you are working with. Then go learn about cgroups at the lowest level. Again you don’t need to master these things but setting up a container from scratch will then give you a more intuitive understanding of what container apis like docker are trying to solve for. Install a hypervisor on your local workstation and set up a few vms networked to each other. Use a tool like netcat to talk across them. Once you have these basics, and yes it is a long and round about way, I think the cloud stuff becomes a lot easier and more approachable since you will have a more in depth understanding of what cloud providers are actually giving you in terms of configurations and managed services. I came into software development from doing sysadmin work at a NOC during a graveyard shift. So I had a lot of time on my hands to mess around with this stuff. I don’t think that tools like docker should be a substitution for the fundementals, but rather something you add to your tool belt later to make these sorts of configurations easier to set up.
Yeah this isn’t going to be a 1-2 day crash course but if you are diligent you can get a basic understanding of what these tools do in under a month. Only after you have a complete understanding of single node use case (e.g. multiple containers running on a single host) would i recommend starting to learn k8. Good luck!
* edit to fix small typos
I recently went down the path of learning it. Even with 6 years of experience using Docker and ~10 years of general deployment / Linux / sysadmin'y experience it took something like 180 hours of no screwing around time to get to the point where I was comfortable putting up a proof of concept production cluster.
Proof of concept in this case means having the cluster up and running to manage multiple services, hooking up multiple external hostnames with external-dns and an AWS Load Balancer controller (I am using EKS). It also involved handling things like running database migrations in a robust way and toying around with nice to haves like preview environments for all PRs. It didn't serve any live customer facing traffic but all of the pieces were there to do it.
The provisioning and managing of the cluster was all adhoc with a mish mash of Bash scripts, eksctl, kubectl and Helm commands. Now I'm transitioning all of that to use Terraform to set up the cluster and every change to the cluster happens through git using ArgoCD to monitor the repo. I'm really happy with the direction things are going. There's no way I could have started here tho, it would have been too many new things to take in at once without knowing the fundamentals.
Long story short, don't try to rush things and skip ahead. It's going to be really important to learn the basics of Kubernetes before trying to automate everything with best practices. I spent a ton of time reading the docs while experimenting with a cluster along with reading hundreds of blog posts and skimming YouTube videos. Every step of the way involved applying what I was learning to a real project and interacting with the cluster in some way.
90% of it was able to be learned with a local cluster running on your dev box.
And even then, I think it took our org a solid year of work from 3 dedicated engineering teams to be comfortably deploying on GKE & EKS.
And still after that investment, we ditched K8s in favor of Nomad.
Kubernetes is kind of like a steamroller where most of us are looking for a hammer.
People joke about Google releasing Kubernetes into the wild to slow down their competition. It's really not that far off from reality though.
Combined with the K8s official docs https://kubernetes.io/docs/home/ and GCP getting started guide, this will give you a good tour of the tech: https://cloud.google.com/gcp/getting-started
For a general overview of DevOps and the principles behind this, you can't go wrong with reading "The DevOps Handbook" and researching the "Accelerate" metrics
Things I started doing was to follow tutorial in k8s, it is a LOT to take in. Install minikube, start with simple Deployment sets and deploy with apply instead of helm. Then you can go from there.
I reckon after you learn k8s all you need to do is to spin up GKE which you should learn after. Depends on what you need, you might need to setup external LB from GCP. I started with nginx-ingress, works amazing, setup the LB automatically and everything.
In summary, k8s docs is your best shot, start slow from tutorial, practice practice and you have to read what's the problem when something fails
Rather than looking how to debug, these 2 commands cover my needs most of the time: kubectl logs <resource-name> kubectl describe <resource-type> <resource-name>
For anyone, who is very fresh in k8s topic and don't won't want to spent a cent for learning I recommend starting from edX course [0]. It provides a nice introduction and great notes, which you can copy as some cheatsheet. Such cheatsheet will be a definitely helpful hand in first weeks with k8s.
For example, for Docker Swarm and the Compose format, you have this: https://docs.docker.com/compose/compose-file/compose-file-v3...
[0] https://kubernetes.io/docs/reference/generated/kubernetes-ap...
[1] kubectl explain deploy --recursive
I know that people like to use something like Kustomize (https://kustomize.io/) and Helm (https://helm.sh/) at least last i checked, but it's also really nice to be able to read up on everything without necessarily following tutorials and such, or using specialized tools.
For example, with Docker Swarm, if i want to change how restarts would be handled, i have a really easy reference available: https://docs.docker.com/compose/compose-file/compose-file-v3...
But with Kubernetes, in the first linked page i find a short description (just scroll down a bit or CTRL+F "restartPolicy") which doesn't offer further parameters: https://kubernetes.io/docs/reference/generated/kubernetes-ap...
To its credit, there is a link to another page as well which contains more information: https://kubernetes.io/docs/concepts/workloads/pods/pod-lifec...
That said, usability wise i'd have to spend more time to figure out how to get my containers/pods restarting just once every 1 minute as opposed to whatever the default is (say, low end cluster with limited resources) with Kubernetes instead of other technologies, due to this difference.
With K8s I guess we are between a really decent (!) documentation that doesn't work very well as a "tutorial", and third party resources that does that.
It does make things harder at the beginning, but is still much better then, say, Hashicorps docs: "here is a cool starting tutorial that covers basics you'll need for the first 30 minutes. That is all, look other things up in the code". For a longer while I felt this was the case with Vault or Consul.
https://kubernetes.io/docs/reference/generated/kubernetes-ap...
The course content is a bit wanting (it sometimes feels more like an advert for GCP products than a course), but if you watch the videos that look relevant and do the labs, I think you’ll get something out of it. Coursera does cost money but has a free trial.
I've been doing these GCP and GKE related courses the last few months as an experienced full-stack developer who is expanding their skill set be to fullerer-stack(?).
The hands-on "labs" might feel like you are mindlessly "following along" with the tutorial but you actually learn quite a lot. The "labs" are also safe in the sense that you can't shoot yourself in the credit card.
Yes, there are clearly some small parts of the courses which were later inserted as ads for new services, but it is not a big deal.
I do recommend learning the basics of what GCP has to offer though and not just concentrating 100% on k8s/GKE.
But in general: learning by building stuff based on a real need -- even if that "need" is just to scratch the itch of some personal project you've always been wanting to do -- has about 10x the staying power (and "interview cred") as what one gets when starting from the mindset of "oh shit, I'm falling behind, I gotta cram on this stuff".
And on top of that: knowing when you really need X or Y, and when you don't -- is often as valuable as, or even more valuable than simply knowing how to do X or Y.
To get the skills for yourself is a different matter: hire a specialist for a day and go through a basic app deployment, workflow and notes for a day. Complement with the basics tutorial to avoid gaps, try your skills on a real environment.
But such infrastructure skills are no joke and mistakes are expensive so I would recommend to take your time learning about it.
Here's my curriculum so far (based on AWS, though):
- Why DevOps (basically, a distilled version of "Accelerate")
- Terraform
- Ansible
- Docker
- Kubernetes
- ELK, Grafana, Prometheus
- Jenkins
- Automated testing
- MLops
- Secret management, databases, database upgrades
(The nature of the $FAMOUS_BOOTCAMP and the requirements from the initial customer makes it more about "here are the specific technologies you might use in your job today" and less about "here's the background principles").
Any suggestions or thoughts?
You blagged your way through a job interview, didn't you?
At least he is trying to learn now instead of pulling a brillant paula.
It's sad that you assume the worst in people.
If you're already comfortable with the basics, then focus on one particular element and master it. The other bits will come over time. I recommend Kubernetes as a focus, given your list.
Keep in mind at all times that the infrastructure serves the business.
That course got me up to speed pretty fast (3 weeks) with docker and k8s. I highly recommend it.
You can work on what is running on your container(s) locally using docker. I would suggest reading thru k8s docs and using minikube (https://kubernetes.io/docs/tutorials/hello-minikube/) to understand things.
Start small and get basics working, then iterate. You will likely experience aha moments later on and want to re-do things. The good thing is you are defining infrastructure via software.
Most people I have encountered who were afraid of k8s also simply did not understand how their process was executed by Linux at all, and I think that was the root of their fears. If you know how it all works, you won’t be afraid of the automation.
With my Terraform framework for AKS, EKS and GKE I'm trying to bring the same framework benefits to the DevOps world, more specifically to Terraform and Kubernetes.
Check it out: https://www.kubestack.com/
https://www.udemy.com/course/certified-kubernetes-administra...
I often see developers or admins who ask questions how to setup their "simple" setup in plain docker on dev machine, while all they have trouble with - networking, volumes, exposing services - is actually very simple with minikube. There is more cool learning resources as well, IMO. It's even easier if you use cloud providers. Creating a working cluster on Scaleway takes a minute and you can't really screw anything up. You'll waste more time looking for a proper credit card, or figuring how basic user auth and privileges work on AWS, etc..
Yes, there is a lot of "magic in the background", but I have not yet seen any developer who reviewed all 1000 dependencies in their Angular Hello World application...
The K8s itself is quite stable from simple user's perspective and does not follow very rapid changes. I am able to easily follow old tutorials, books and documentation that was not updated in a long time without much issues. If something was broken I usually knew how to fix that after first basic k8s training. Core concepts did not change much, or at all. Some things got tidied up, like storage abstraction, but it makes sense and it's nothing new. A lot of cloud integration is build into K8s for years, some integrations like ... ingresses that implement certain external products are delivered mostly by vendors and it's quite easy to find options available.
There is a lot of mess into implementing proper production or large scale setup, misconceptions on how storage is handled and "why plain k8s does not provide Read Write Many storage out of the box?" kind of questions at the start. But a lot of that are issues that exist in any on premise infrastructure and has to be handled with a personal touch - taking in to account what you already have.
Setting up only the cluster? - Start by porting your local setup to a local k8 (minikube etc.)
And i would suggest to invest some time into terraform to setup everything the way you want it.
All of setup step is simple, there're many resources that you can follow and learn all in 1,2 days.
Just think how things stick together first.