Related to meetup: https://www.meetup.com/Kubernetes-Tel-Aviv/events/248536747/
Codefresh - using Helm to provision ad-hoc environments
Oleg from Codefresh will share how they have used Helm to spin up an complete working version of their product (including all services and dependencies) on each commit, allowing developers and other stakeholders to test, experiment, and communicate on work in progress.
Oleg is working as Backend engineer at Codefresh, a Kubernetes native CI/CD platform.
For the past year focusing on #helm and #K8S in research and implementation of Codefresh roadmap.
In his spare time Oleg is maintaining his own projects, traveling and reading.
The demo application: https://github.com/olegsu/kubernetes-tlv
2. Codefresh is a DevOps Platform
Built for Kubernetes
Kubernetes
CI/CD Pipelines
Self-Service Test
Environments
Docker & Helm
Registry
Release
Management
3. Codefresh tech overview
● The boring stuff:
○ Micro-services, HTTP
○ Node.js / Go code repos in Github
○ Running on Kubernetes
● The interesting stuff:
○ Deploying using Helm
○ One chart per service
○ Charts grouped under one master-chart using ‘local-charts’
codefresh
├── env
│ ├── production
│ ├── staging
│ ├── dynamic
├── files
│ ├── ...
├── local-charts
│ ├── accounts-referrals
│ ├── builder
│ ├── cfapi
│ ├── cfsign
│ ├── charts-manager
│ ├── cluster-providers
│ ├── context-manager
│ ├── internal-status-page
│ ├── kube-integration
│ ├── mailer
│ ├── payments
│ ├── pipeline-manager
│ ├── runner
│ ├── salesforce-reporter
│ ├── segment-reporter
│ ├── tasker-kubernetes
│ └── workflow-baseline-invoker
└── templates
├── ...
6. Before
1. Developer push changes to source
control
2. Pipeline build docker image
3. Developer tags docker image
7. Before
1. Developer push changes to source
control
2. Pipeline build docker image
3. Developer tags docker image
4. Developer update image tag in
helm chart
8. Before
1. Developer push changes to source
control
2. Pipeline build docker image
3. Developer tags docker image
4. Developer update image tag in
helm chart
5. Pipeline deploys Helm chart
9. Before
Challenges:
● Manual steps are error prone
● Multiple steps need to be
synchronized
● Lack of traceability
● Bottleneck on destination
environment
12. New rules
● Move charts into the code repo
● Use default values, charts installable without values file (dev)
● Values are embedded in the chart, part of the Helm package artifact
● No multi-image charts
● Consistent version across: Code (package), Container image, Git release, Helm
chart
● Use Semantic versioning throughout assets
● Chart-of-Charts becomes a composition of charts using requirements.yaml
14. Looking Forward
● Break down into smaller pipelines using triggers
○ We recently launched pluggable triggers, including out of box support for Docker Hub
● Encapsulated steps/plugins
○ We are working on templating reusable steps
● Advanced chart management - channels, auth, metadata
○ Actively developing Chart Museum