Microservices are ‘easy’ dependencies are hard
- 1. @itielshwartz Microservices are ‘easy’ dependencies are hard: The right way to build a cloud-native CI/CD Itiel Shwartz
- 2. @itielshwartz About me Joined Rookout as a first developer and production engineer Previously Worked at Forter and eBay as a backend engineer @itielshwartz on both Github and Twitter personal blog at: https://etlsh.com
- 4. @itielshwartz So is this talk going to be - why K8S and helm are so awesome?
- 6. @itielshwartz • People tend to abuse it • We are going to talk about moving fast, while staying alive • By the end of this session, you will be more proficient on how to use K8S (Superhero)
- 7. @itielshwartz 1. Build a basic app 2. K8S it 3. See why K8S isn’t enough 4. Helm it 5. Little Jenkins CI/CD 6. Conclusion
- 10. @itielshwartz Docker Docker is a tool designed to make it easier to create, deploy, and run applications by using containers*
- 11. @itielshwartz Pod A Kubernetes pod is a group of containers that are deployed together on the same host. If you frequently deploy single containers, you can generally replace the word "pod" with "container" and accurately understand the concept. Deployment A Deployment controller provides declarative updates for Pods and ReplicaSets.
- 12. @itielshwartz K8S is so easy!
- 14. @itielshwartz Backend Service DAL Service User Ask for a quote Backend logic - random a quote number Fetch quote by id
- 15. @itielshwartz
- 17. @itielshwartz
- 18. @itielshwartz Now we can get and search quotes :)
- 20. @itielshwartz
- 21. @itielshwartz All I need is to revert the DAL Phew... this was close
- 22. @itielshwartz Ok, let’s not panicOk, let’s not panic
- 23. @itielshwartz All I need is to revert everything...
- 24. @itielshwartz Ok let’s not panic I thought microservice are the best!
- 25. @itielshwartz 1. We write a lot of boilerplate for each microservice • Deployment.yaml , service.yaml, LB.yaml , configmap.yaml 2. No easy way testing those microservices before prod • we need to configure each env 3. No version control for the dependencies between microservices!!!
- 26. @itielshwartz 1. The ability to deploy new code to production - everyone is talking about it! 2. The ability to test the system e2e very fast before going to production 3. Fast rollback - Your system will break! Not a question of if, but a question of when.
- 27. @itielshwartz Helm to the rescue
- 28. @itielshwartz Helm describes itself as the “The package manager for Kubernetes” sounds pretty straightforward right? No? Maybe? Does it help you to Download packages? Upload packages? Deploy envs? State control? Cluster control? Templating?
- 29. @itielshwartz • CHART • REPOSITORY (REPO, CHART REPOSITORY) • RELEASE
- 30. @itielshwartz Chart A chart is organized as a collection of files inside of a directory. The directory name is the name of the chart (without versioning information). Thus, a chart describing WordPress would be stored in the wordpress/ directory*
- 31. @itielshwartz
- 32. @itielshwartz Backend Service DAL Service User Ask for a quote Backend logic - random a quote number Fetch quote by id Redis cache layer add quote Fetch quoteCheck if quote exist
- 33. @itielshwartz The requirements file is one of the most “overlooked” features helm has to offer, and one of its greatest! It allows us to: ● Add external dependencies ● Deploy multiple services in “one-shot” Redis helm
- 35. @itielshwartz We created a single file with all microservices, and to specify a version for each one. ● We can use a remote repository. One chart to rule them all
- 36. @itielshwartz The power of a single helm chart for deployment: 1. We now have a single-source of truth about our microservices versions. 2. We can rollback to a previous deployment (and by that revert all changes in all microservices) . (helm rollback X) 3. We can Deploy to a new namespace! Meaning adding prod env and staging env using the same files. (helm --namespace prod) 4. We can inject different variable based on the env we are deploying to (using the values.yaml files) (helm -f prod.yaml)
- 37. @itielshwartz Treat your CI/CD like cattle, not pets!
- 38. @itielshwartz CI/CD blueprint for helm and K8S Full helm microservice multiple repo ci/cd pipeline example: 1. Push to branch. 2. Build the docker. 3. Bonus: Use multistage docker build to run tests 4. Build the helm package. If building master: 5. Try and update the umbrella chart (update backend from 1.0.x -> 1.0.x+1) 6. Deploy to staging/dev namespace 7. If it works - great! (and maybe auto move to prod) 8. If it fails -> revert the umbrella chart change (and maybe revert the backend branch)
- 39. @itielshwartz Long live Jenkins! Death to Jenkins!
- 40. @itielshwartz Jenkins CI/CD, Helm and K8S 1. With Jenkins shared-libraries we can create a full pipeline that will be shared across all repos. 2. When adding a new micro service we don’t need to write a single line of code! 3. This also allow us to config all of our CI/CD as code (Groovy). 4. Using Jenkins and helm we can create a full CI/CD pipeline that is standard across all microservices. 5. Jenkins has it own Helm chart - little meta but works :) 6. On the other hand - Jenkins.
- 41. @itielshwartz Conclusion 1. Managing microservice is hard. 2. Helm can make it easier. 3. All source code can be found on my github: https://github.com/itielshwartz/microservices-using-helm We live in a cool time, where the problem is not deploying - but deploying too fast :)
- 42. @itielshwartz K8S HELM Like peanut butter and jelly @itielshwartz