Cloud Native CI/CD with GitOps
3 likes588 views
Kasper Nissen discusses the implementation of GitOps for continuous integration and delivery (CI/CD) at Lunar Way, emphasizing its benefits over traditional methods, such as faster deployment times, improved security, and a clear audit trail. By leveraging GitOps, configuration is managed through git repositories, minimizing manual intervention and allowing for reproducible builds. The transition addressed previous issues related to long change lead times and inadequate disaster recovery processes.
More Related Content
Similar to Cloud Native CI/CD with GitOps (20)
![[Devopsdays2021] Roll Your Product with Kaizen Culture](https://cdn.slidesharecdn.com/ss_thumbnails/devopsdays2021rollyourproduct-210415064545-thumbnail.jpg?width=560&fit=bounds)
Cloud Native CI/CD with GitOps
- 1. Cloud Native CI/CD with “GitOps” DevOpsDays Copenhagen 2019 Kasper Nissen, Cloud Architect/SRE @lunarway [email protected] @phennex
- 2. $ whoami Kasper Nissen (@phennex) ● Cloud Architect / Site Reliability Engineer @lunarway ● Organizer and Co-Founder at Cloud Native Aarhus ● Founder of Cloud Native Nordics Slack Community ● Blogger at kubecloud.io @phennex
- 3. What is Lunar Way? Our vision is to rethink the interaction with money. Live in Sweden, Norway, and Denmark 3 Kubernetes clusters in AWS 80+ microservices in production @phennex
- 4. Continuous integration is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early. - - - Continuous delivery is the ability to get changes of all types - including new features, configuration changes, bug fixes and experiments - into production, or into the hands of users, safely and quickly in a sustainable way. @phennex
- 5. This sounds like two different concerns? … aren’t we all about decomposing, into smaller components with single responsibility? @phennex
- 6. ? CI/CD do we trust this guy with everything related to our pipeline, and basically with access to all our environments? CI CD Separating CI/CD into separate concerns as per the definition The monolith Single Responsibility (microservices?) @phennex
- 7. GitOps is an extension of infrastructure as code that can be applied to Kubernetes workloads. Configuration of applications is stored in Git that can be deployed automatically from Git and left untouched by manual operator intervention. The term was coined by Alexis Richardson and the great folks at weaveworks Introducing GitOps @phennex
- 8. CI/CD at Lunar Way (before) @phennex
- 9. Problems? ● Long change lead time - because of multiple builds ● Building images for each branch is not feasible ● Jenkins has R/W access to the Kubernetes cluster ● No audit trail of deployments ● Branching hell git checkout dev && git pull origin dev && git merge master && git push origin dev && git checkout staging && git pull origin staging && git merge dev && git push origin staging && git checkout prod && git pull origin prod && git merge staging && git push origin prod && git checkout master “Awesome” promote command to all environments @phennex
- 10. Problems? ● No “source of truth” of what is running making it hard in a disaster recovery situation @phennex
- 13. The responsibility of Continuous Integration is to ensure quality by executing test, checks, and scans of the code before handing it over. Continuous Integration shuttle run build shuttle run push tag=tag https://github.com/lunarway/shuttle Minimize groovy code to allow for easy migration @phennex
- 14. A build artifact is a JSON-blob that follows all builds from the CI pipeline. It contains all relevant information about the build. Build Artifacts ● Shuttle plan information ● CI info and links ● Stage information ○ Test information ○ Security Scan information @phennex
- 15. The responsibility of Release Manager is to control promotion of artifacts between environments, and enable developers/operators to easily operate their services. Release Manager ● Listen for changes in a git repository, e.g. in /builds ● Move files between folders (environments) ● Report state changes back to clients @phennex
- 16. The responsibility of Release Operator is to ensure that the environment is synchronized with the configuration repository Release Operator ● Weaveworks flux (OSS) ● Listens for changes and applies kubernetes yaml in the cluster it is deployed @phennex
- 17. The responsibility of the Release Daemon is to communicate changes in the environment back to the release manager. Both successful releases and failures. Release Daemon ● Listens for changes in the kubernetes environment it is running in ● Reports the state back, and extract relevant information @phennex
- 18. The goal is to provide our developers with the information and tooling they need. Minimizing the feedback loop. Developer Workflow Slack Integration CLI @phennex
- 19. Adopting a modified GitOps pattern has improved a lot of the previous pain points Wrapping up, what did we get? ● Faster lead time to production ● Promotion of artifacts instead of code (reproducible builds) ● Current state of the cluster is always stored in git and can easily be recreated @phennex
- 20. Continued Wrapping up, what did we get? ● Minimizing the need for developer access to the environments (minimize the risk of exposing credentials and human errors) ● CI no longer have access to the cluster, minimizing the surface of attack ● Audit trail of changes @phennex Thank You!we are hiring https://jobs.lunarway.com/