Download to read offline
![The Route directs to the Service application0
➜ ~ oc export routes application0
apiVersion: v1
kind: Route
[...]
spec:
host: application0-presentation...
to:
kind: Service
name: application0
weight: 100
[...]
@barkerd427](https://image.slidesharecdn.com/architectingthefuture-ato-171030224426/85/Architecting-the-Future-Abstractions-and-Metadata-All-Things-Open-41-320.jpg)
![The Pod has many labels.
➜ ~ oc export -o yaml po/application0-1-ao16l
apiVersion: v1
kind: Pod
metadata:
labels:
app: application0
deploymentconfig: application0
environment: dev
partition: customerA
release: stable
tier: frontend
[...]
@barkerd427](https://image.slidesharecdn.com/architectingthefuture-ato-171030224426/85/Architecting-the-Future-Abstractions-and-Metadata-All-Things-Open-43-320.jpg)
![The Pod has many labels.
➜ ~ oc export -o yaml po/application0-beta-1-ao16l
apiVersion: v1
kind: Pod
metadata:
labels:
app: application0-beta
deploymentconfig: application0-beta
environment: dev
partition: customerA
release: stable
tier: frontend
[...]
@barkerd427](https://image.slidesharecdn.com/architectingthefuture-ato-171030224426/85/Architecting-the-Future-Abstractions-and-Metadata-All-Things-Open-47-320.jpg)
Uploaded byDaniel Barker
Architecting the Future: Abstractions and Metadata - All Things Open
The document discusses the architecture of data centers and the evolving use of abstractions in software development, particularly focusing on tools like Docker, Kubernetes, and OpenShift. It emphasizes the importance of pipelines for deployment and security, highlighting how services and routes facilitate application usability. Additionally, it touches on the significance of metadata and operational knowledge encapsulated in software, underscoring the need for dynamic approvals and consistent security measures in application development.
More Related Content
Similar to Architecting the Future: Abstractions and Metadata - All Things Open
Architecting the Future: Abstractions and Metadata - All Things Open
- 1. Architecting the Future Abstractionsand Metadata Dan Barker @barkerd427 danbarker.codes
- 2.
- 3. “All non-trivial abstractions, to somedegree, are leaky.” - Joel Spolsky @barkerd427
- 4. The current datacenter is...challenging... RHEL 7.4 Dev RHEL 7.3 Test RHEL 7.1 Prod Dev Test Prod RHEL 7.2 Prod Admin Admin Admin Admin Admin Admin Dev RHEL 7.2 Dev RHEL 7.1 Dev RHEL 7.3 Dev Ubuntu Trusty RHEL 7.4 Dev RHEL 6.6 Dev Ubuntu Trusty RHEL 7.3 Dev RHEL 7.4 Dev RHEL 7.2 Dev Ubuntu Trusty RHEL 6.9 Dev RHEL 7.1 Dev RHEL 7.4 Dev RHEL 7.1 Dev RHEL 7.3 Dev Ubuntu Trusty RHEL 6.9 Dev RHEL 7.2 Dev @barkerd427
- 6. The new datacenter is understandable and usable. Developer Access Production Controlled Network Storage Compute Platform Deployment Pipeline RHEL 7.4 App1 RHEL 7.4 App1 RHEL 7.4 App1 RHEL 7.4 App1 RHEL 7.4 App1 RHEL 7.4 App1 RHEL 7.4 App2 RHEL 7.4 App2 RHEL 7.4 App2 RHEL 7.4 App2 RHEL 7.4 App2 RHEL 7.4 App2 @barkerd427
- 7. Docker - theearly ● Docker is an abstraction ○ cgroups ○ Namespaces @barkerd427 ● Not Included ○ Metadata ○ Volumes ○ Secrets ○ Services ○ Network
- 8. Docker - thelatter ● Volumes ● Secrets ● Networks @barkerd427 ● Plugins ● Services ● Labels
- 9.
- 10.
- 11. Kubernetes (k8s) ● PersistentVolumes ●Services ● Pods ● Secrets @barkerd427 ● Ingress ● DaemonSets ● ReplicaSets ● Deployments
- 12.
- 13. OpenShift ● Routes >Ingress ● DeploymentConfig > Deployments @barkerd427 ● ImageStream ● BuildConfig
- 14.
- 16.
- 17. ImageStreams ● Contains imagesfrom: ○ Integrated registry ○ Other ImageStreams ○ External registries ● Automatic event triggers http://blog.openshift.com @barkerd427
- 18. ImageStreams - Metadata ●Commands ● Entrypoint ● EnvVars @barkerd427 ● Layers ● Labels ● Ports
- 19.
- 22.
- 23. Operators ● Represents human operationalknowledge in software ● Uses 3rd-party resources ○ Controller of controllers and resources @barkerd427 ● Identical model to k8s controllers ○ OODA Loop ● Not supported in OpenShift ● CustomResource Definitions ○ Extends Kubernetes API ● Now in Beta!!!
- 24. Operators ● Deployed intok8s cluster ● Interactions through new API ○ kubectl get prometheuses ○ kubectl get alertmanagers @barkerd427 ● Abstraction around k8s primitives ○ Users just want to use a MySQL cluster. ● Complex tasks that can be performed ○ Rotating credentials, certs, versions, backups
- 27. Istio is abridge to the future
- 28. Istio ● Service Mesh ○Traffic Management ○ Observability ○ Policy Enforcement ○ Service Identity and Security ● Kubernetes support and limited VM support
- 29.
- 30. Pipelines ● Stages ● Steps ●Application ● EnvironmentSet @barkerd427 ● PipelineTemplate ● PipelineConfig ● BuildConfig ● DeployConfig
- 31. An Application includesa Pipeline, based on an opinionated PipelineTemplate. These combine as a PipelineConfig. apiVersion: v1 kind: Application name: app1 cap: template: name: approvedTemplates/Tomcat8.yaml pipeline: notifications: mattermost: team: cloud channel: general on_success: never on_failure: always dependencies: - name: authn dnsName: authn - name: key-management username: reference_to_username password: reference_to_password stages: - name: build steps: - action: build baseImage: version: 8.0.41 - name: dev approvers: - role: app1-dev steps: - action: deploy params: environment: dev apiVersion: v1 kind: PipelineTemplate name: Tomcat8 labels: type: application build: manager: maven version: latest builderImage: java8-builder version: latest baseImage: tomcat8 version: latest deploy: deploymentType: canary maxUnavailable: 10% maxSurge: 20% apiVersion: v1 kind: PipelineConfig name: app1-pipeline labels: type: application pipeline: notifications: mattermost: team: cloud channel: general on_success: never on_failure: always dependencies: - name: authn dnsName: authn - name: key-management username: reference_to_username password: reference_to_password stages: - name: build steps: - action: build manager: maven builderImage: java8-builder baseImage: tomcat8 version: 8.0.41 - name: dev approvers: - role: app1-dev steps: - action: deploy params: environment: dev @barkerd427
- 32. An Application andPipelineTemplate also combine to create a DeploymentConfig. apiVersion: v1 kind: Application name: app1 cap: template: name: approvedTemplates/Tomcat8.yaml pipeline: notifications: mattermost: team: cloud channel: general on_success: never on_failure: always dependencies: - name: authn dnsName: authn - name: key-management username: reference_to_username password: reference_to_password stages: - name: build steps: - action: build baseImage: version: 8.0.41 - name: dev approvers: - role: app1-dev steps: - action: deploy params: environment: dev apiVersion: v1 kind: PipelineTemplate name: Tomcat8 labels: type: application build: manager: maven version: latest builderImage: java8-builder version: latest baseImage: tomcat8 version: latest deploy: deploymentType: canary maxUnavailable: 10% maxSurge: 20% apiVersion: v1 kind: DeploymentConfig metadata: name: app1-pipeline type: application spec: replicas: 2 selector: name: frontend template: { ... } triggers: - type: ConfigChange - imageChangeParams: automatic: true containerNames: - helloworld from: kind: ImageStreamTag name: hello-openshift:latest type: ImageChange strategy: type: Rolling @barkerd427
- 33. The value ofPipelines ● Abstract audit and compliance ○ Approvals added dynamically ● Trivialities eliminated ○ Tabs vs. spaces ○ Semicolons or not ● Security checks occur early and often ○ Feedback is important @barkerd427
- 34. The value ofPipelines ● Test all the things! ● Nimble security ● Common artifact repositories ○ Restrict dependencies ○ Automated security vulnerability notification ● Standardized/Centralized approval system ● Applications will become secure by default @barkerd427
- 36.
- 37. Services make your appusable @barkerd427
- 38. Services ● Identifies podsusing label selectors ○ Any label ○ Specific to avoid errant selections ● Passes requests to pods internally ○ Routes and Services are different ● Abstraction for a Route to pass traffic @barkerd427
- 39.
- 40. One Route, OneService, One Application Route Service Pod @barkerd427
- 41. The Route directsto the Service application0 ➜ ~ oc export routes application0 apiVersion: v1 kind: Route [...] spec: host: application0-presentation... to: kind: Service name: application0 weight: 100 [...] @barkerd427
- 42. The Service matcheson the label “deploymentconfig” with the value “application0”. ➜ ~ oc export svc application0 apiVersion: v1 kind: Service spec: selector: deploymentconfig: application0 @barkerd427
- 43. The Pod hasmany labels. ➜ ~ oc export -o yaml po/application0-1-ao16l apiVersion: v1 kind: Pod metadata: labels: app: application0 deploymentconfig: application0 environment: dev partition: customerA release: stable tier: frontend [...] @barkerd427
- 44. The Service nowmatches on the label “tier” with the value “frontend”. ➜ ~ oc export svc application0 apiVersion: v1 kind: Service spec: selector: tier: frontend @barkerd427
- 45. One Route, OneService, Two Applications Route Application Application Service Service @barkerd427
- 46. Curling the sameRoute results in two different applications responding. @barkerd427
- 47. The Pod hasmany labels. ➜ ~ oc export -o yaml po/application0-beta-1-ao16l apiVersion: v1 kind: Pod metadata: labels: app: application0-beta deploymentconfig: application0-beta environment: dev partition: customerA release: stable tier: frontend [...] @barkerd427
- 48. We’ve deleted application1and added application0-beta. @barkerd427