Interop 2017 - Managing Containers in Production
•Download as PPTX, PDF•
2 likes•1,254 views
Managing Containers in Production discusses planning for containerized applications in production environments. It covers container registries, CI/CD, networking, storage, security, scaling, application services, and comparing container schedulers like Kubernetes and Docker Swarm. The document provides URLs for further reading on container orchestrator architectures and advises that while creating containers is easy, managing them at scale in production can be complex and requires consideration of these operational aspects.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Interop 2017 - Managing Containers in Production
Similar to Interop 2017 - Managing Containers in Production (20)
More from Brian Gracely
More from Brian Gracely (13)
Recently uploaded
Recently uploaded (20)
Interop 2017 - Managing Containers in Production
- 1. Managing Containers in Production Brian Gracely Director Strategy, Red Hat @bgracely | bgracely@redhat.com
- 2. • Brian Gracely (@bgracely) • Director Strategy, Red Hat OpenShift • Co-Host of The Cloudcast | The ServerlessCast • Formerly EMC {code}, Virtustream, Cisco, NetApp, Linksys, Wikibon
- 3. Creating a container on your laptop is easy. Making it work in production can be very complicated. Learn how to plan for Container Registries, CI/CD, Networking, Storage, Security, Scaling and Application Services for your containerized application. Includes insight on Kubernetes, Cloud Foundry, Docker Swarm and Mesos.* * Deferred to some URLs for your reading pleasure (on the next slide)
- 4. Comparing Container Schedulers • Kubernetes vs. SwarmKit : https://platform9.com/blog/compare- kubernetes-vs-docker-swarm/ • Kubernetes vs. Mesos : https://platform9.com/blog/compare- kubernetes-vs-mesos/ • Cloud Foundry Diego Architecture : https://docs.cloudfoundry.org/concepts/diego/diego-architecture.html
- 5. What’s the Ultimate Goal? API Traffic LB APP1 APP2 Microservices DATA DATA DATA
- 6. Container Usage Grows Quickly
- 7. Eventually You Need a Platform / Orchestrator
- 9. The Battle for Container Orchestration CONFIDENTIAL - FOR INTERNAL USE ONLY Kubernetes Mesos Others Cloud Foundry Diego AWS Blox Rancher Cattle VMware Admiral HashiCorp Nomad CoreOS Fleet SwarmKit
- 13. “Node” Instances – Where Applications Run
- 14. Applications Run in Containers Container Image Container Pod
- 15. “Pods” are the Unit of Orchestration
- 16. 16 “Masters” are the Control Plane
- 17. 17 Master - API and Authenticator
- 18. 18 Master – Desired and Current State
- 19. 19 Master - Orchestration and Scheduling
- 20. 20 Master – Node Placement by Policy
- 21. 21 Master – Service Discovery
- 22. NETWORKING
- 23. 23 • Pluggable routing architecture • HAProxy Router • F5 Router • Multiple-routers with traffic sharding • Router supported protocols • HTTP/HTTPS • WebSockets • TLS with SNI • Non-standard ports via cloud load-balancers, ExternalIP, and NodePort ROUTING AND LOAD-BALANCING
- 24. 24 ROUTE SPLIT TRAFFIC SERVICE A App A App A SERVICE B App B App B ROUTE 10% traffic 90% traffic Split Traffic Between Multiple Services For A/B Testing, Blue/Green and Canary Deployments
- 25. NODE IP-3 NODE IP-2 NODE IP-1 25 EXTERNAL TRAFFIC WITH EXTERNALIP SERVICE EXT: IP-10:8080 INT: INT-IP:8080 EDGE ROUTERS IP-10, IP-11, IP-12 POD Port: 8080 POD Port: 8080 POD Port: 8080 IP FAILOVER POD IP FAILOVER POD connect IP-10:8080 CLIENT• Route external traffic to a service on any TCP/UDP port • Available on non-cloud clusters • External IP automatically assigned from a pre-defined pool of external IPs • IP failover pods provide high availability for the pool of external IPs
- 26. • NodePort exposes a unique port on all the nodes in the cluster • Ports in 30K-60K range which usually differs from the service • Traffic received on any node redirects to a node with the running service • Firewall rules must allow traffic to all nodes on the specific port NODE IP-3 NODE IP-2 NODE IP-1 26 EXTERNAL TRAFFIC WITH NODEPORT SERVICE INTERNAL-IP:8080 NODEPORT: 32010 POD Port: 8080 POD Port: 8080 POD Port: 8080 connect IP-1:32010 CLIENT
- 27. 27 CONTROL SOURCE IP WITH EGRESS ROUTER NODE IP1 EGRESS ROUTER POD IP1 EGRESS SERVICE INTERNAL-IP:8080 EXTERNAL SERVICE Whitelist: IP1 POD POD POD
- 28. 28 • Built-in DNS to enable reaching services by DNS • Split DNS is supported via SkyDNS • Master answers DNS queries for internal services • Other nameservers serve the rest of the queries • Software Defined Networking (SDN) for a unified cluster network to enable pod-to-pod communication • OpenShift follows Kubernetes network plug-in model (CNI) • Supported plug-ins • OpenShift SDN (Open vSwitch or Flannel) • Nuage SDN (Virtualized Services Platform) PLATFORM NETWORKING
- 30. 30 PERSISTENT STORAGE • Persistent Volume • Tied to a piece of network storage • Provisioned by an administrator (static or dynamically) • Allows admins to describe storage and users to request storage NFS GlusterFS OpenStack Cinder Ceph RBD AWS Elastic Block Store (EBS) GCE Persistent Disk iSCSI Fibre Channel
- 31. PROJECT POOL OF PERSISTENT VOLUMES 31 PERSISTENT STORAGE – PERSISTENT VOLUMES (PV) NFS PV iSCSI PV NFS PV Admin User register PV create claim NFS PV GlusterFS PV Pod claim Pod claim Pod claim Ceph RBD PV
- 32. 32 DYNAMIC VOLUME PROVISIONING Admin User define StorageClass create claim: Fastest Slow Azure-Disk Fast AWS-SSD Fastest NetApp-Flash NetApp Provisioner AWS Provisioner Pod claim PV Kubernetes PV Controller provision Azure Provisioner bound
- 34. CENTRALIZED LOG MANAGEMENT APPLICATION LOGS OPERATION LOGS ELASTIC ELASTIC 34 RHEL NODE POD POD PODPOD FLUENTD RHEL NODE POD POD PODPOD FLUENTD ELASTICSEARCH RHEL NODE POD POD PODPOD FLUENTD USER ELASTIC ELASTIC KIBANA ELASTIC ELASTIC ELASTICSEARCH ELASTIC ELASTIC KIBANA ADMIN
- 36. CONTAINER METRICS 36 RHEL NODE POD POD PODPOD FLUENTD CONTAINER METRICS RHEL NODE POD POD PODPOD FLUENTD HEAPSTER RHEL NODE POD POD PODPOD CADVISOR HAWKULAR WEB CONSOLE ELASTIC ELASTIC CASSANDRA CLOUD MANAGEMENT CUSTOM DASHBOARDS API USER
- 37. SECURITY
- 38. 38 TEN LAYERS OF CONTAINER SECURITY Container Host & Multi-tenancy Container ContentContainer Registry Building Containers Deploying Container Container Platform Network Isolation Storage API Management Federated Clusters
- 39. NODE MASTER • Secure mechanism for holding sensitive data e.g. • Passwords and credentials • SSH Keys • Certificates • Secrets are made available as • Environment variables • Volume mounts • Interaction with external systems • Encrypted in transit • Never rest on the nodes 39 SECRET MANAGEMENT Container Distributed Store Container
- 41. 41 TOP CHALLENGES OF RUNNING CONTAINERS AT SCALE SERVICE HEALTH SECURITY & COMPLIANCE FINANCIAL MANAGEMENT OPERATIONAL EFFICIENCY
- 46. BUILD & DEPLOY CONTAINER IMAGES
- 47. 47 BUILD AND DEPLOY CONTAINER IMAGES DEPLOY YOUR SOURCE CODE DEPLOY YOUR APP BINARY DEPLOY YOUR CONTAINER IMAGE
- 49. 49 DEPLOY SOURCE CODE codeGit Repository Source-to-Image (S2I) deploy CODE BUILD DEPLO Y Container Image Image Registry OPSDEV Application Container Build Packs
- 51. DEPLO Y 51 DEPLOY APP BINARY buildApplication Binary (e.g. WAR) Source-to-Image (S2I) deploy Container Image Image Registry OPSDEV BINARY BUILD IMAGE Existing Build Process Application Container Build Packs
- 53. DEPLO Y 53 DEPLOY CONTAINER IMAGE build Application Container deploy Application Image Image Registry OPSDEV BUILD Existing Image Build Process
- 54. CONTINUOUS INTEGRATION (CI) CONTINUOUS DELIVERY (CD)
- 55. CI/CID WITH BUILD AND DEPLOYMENTS 55 BUILDS • Webhook triggers: build the app image whenever the code changes • Image trigger: build the app image whenever the base language or app runtime changes • Build hooks: test the app image before pushing it to an image registry DEPLOYMENTS • Deployment triggers: redeploy app containers whenever the image changes in the Kubernetes image registry or upstream registries
- 56. 56 CONTINUOUS DELIVERY WITH CONTAINERS source repository CI/CD engine dev container physical virtual private cloud public cloud
- 57. CONTINUOUS DELIVERY PIPELINE INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER 57 DEVELOPER GIT SERVER ARTIFACT REPOSITORY OPENSHIFT CI/CD PIPELINE (JENKINS) IMAGE BUILD & DEPLOY INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER NON-PROD PRODDEV
- 58. INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER 58 CONTINUOUS DELIVERY PIPELINE DEVELOPER GIT SERVER ARTIFACT REPOSITORY OPENSHIFT CI/CD PIPELINE (JENKINS) IMAGE BUILD & DEPLOY INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER PROMOTE TO TEST NON-PROD PRODDEV TEST
- 59. INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER 59 CONTINUOUS DELIVERY PIPELINE DEVELOPER GIT SERVER ARTIFACT REPOSITORY OPENSHIFT CI/CD PIPELINE (JENKINS) IMAGE BUILD & DEPLOY INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER PROMOTE TO TEST PROMOTE TO UAT NON-PROD PRODDEV TEST UAT
- 60. INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER 60 CONTINUOUS DELIVERY PIPELINE DEVELOPER GIT SERVER ARTIFACT REPOSITORY OPENSHIFT CI/CD PIPELINE (JENKINS) IMAGE BUILD & DEPLOY INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER GO LIVE? PROMOTE TO TEST PROMOTE TO UAT RELEASE MANAGER NON-PROD PROD ☒ ☑ DEV TEST UAT
- 61. INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER 61 CONTINUOUS DELIVERY PIPELINE DEVELOPER GIT SERVER ARTIFACT REPOSITORY OPENSHIFT CI/CD PIPELINE (JENKINS) IMAGE BUILD & DEPLOY INTEGRATED IMAGE REGISTRY KUBERNETES CLUSTER GO LIVE? PROMOTE TO TEST PROMOTE TO UAT PROMOTE TO PROD RELEASE MANAGER NON-PROD PRODDEV TEST UAT ☒ ☑
- 62. KEY TAKEAWAYS
- 63. • Containers are relevant for both developers and operators, but in different ways. Establishes a common language for deployments. • Containers are the new packaging model for both existing and new applications. • Container platforms operationalize the management of containers. • Container workloads need a new way of thinking about networking, storage, monitoring, logging, etc. Key Takeaways
- 64. NEXT STEPS
- 65. • Learn about Containers – PluralSight (Docker, Nigel Poulton) • Learn about Orchestration - https://katacoda.com/ (Kubernetes, OpenShift, Docker, etc.) • Attend local Meetups to Network – http://meetup.com • Setup a Local (or cloud) Environment for FREE – Docker for Mac/Windows, MiniKube, MiniShift, AWS Quick Starts, etc. Next Steps – Getting Smarter
- 66. THANK YOU
Editor's Notes
- The listed vendors build and sell solutions based on the specified orchestration framework
- OpenShift SDN can be configured to use Flannel instead of Open vSwitch. This is useful if running OpenShift Container Platform within a cloud provider platform that also relies on SDN, such as OpenStack, and you want to avoid encapsulating packets twice through both platforms.
- Administrators define a pool of Persistent Volumes (PV) which are backed by network storage solutions like NFS, iSCSO, AWS EBS, etc and make them globally available in the OpenShift cluster. Users within their projects can create a Persistent Volume Claim (PVC) in order to request a PV to be available within their pods. In the pod definition, a developer can refer to the PVC and mount the requested persistent volume inside the pod at an arbitrary path. If a pod gets restarted, OpenShift mounts the same persistent volume into the pod again so that the pod data is available. PVs outlive the containers that were using them.
- Continuous Integration (CI) means that the developer's working copies are synchronized with the share code repository several times a day. The code is built, integrated and unit tested every time a change is pushed to the shared code repository Continuous Delivery (CD) is an extension of CI always be ready to deploy a product into production, but deploy to production requires manual approval Continuous Deployment is the next step after gaining more confidence in the process, to automatically deploy the product into production whenever it passes QA.
- The deployment pipeline pauses for the approval of release manager, deployment manager, etc. This step is typically integrated into the existing IT workflow management system such as ServiceNow, JIRA Service Desk, etc so that eligible user groups receive notification when a deployment requires approval. They would in that case be able to log in into their IT workflow management dashboard and approve or reject the production deployment based on the provided deployment details.